As the electronic devices have turned into complex, most of them have been equipped with an operating system. Operating system is loaded into the memory of the device when the device is turned on. Because of the complexity of the tasks that need to be processed with such devices also the operating systems have turned into complex pieces of software. It is commonly known that complex pieces of software do not function perfectly as they have bugs that usually derive from programming errors. When a regular piece of software crashes because of a bug, it is common to start a debugging tool and check the reason of the crash. However, this might not be possible in case of operating system crash. If the operating system crashes the only solution to continue using it might be rebooting. During the reboot all crash information will be lost. Thus, the debugging is not possible.
This problem has been solved by storing the contents of the RAM memory. In ordinary computers RAM-contents can be stored into a swap partition on a disk. After a crash the computer is booted again but the swap is not cleared. Thus, the contents of the memory during the crash can be analyzed and debugged. Naturally, this solution does not work in a diskless system as there is no swap partition to be used.
One solution could be sending the crash information over a network connection to another computing device that has disk or other storage media for storing the information. However, the communication over a network connection requires properly functioning network device driver and protocol stack. This might not be the case if the system crashes during the boot up sequence. Furthermore, this solution is not applicable if the device does not have network connection at all or the network connection is not suitable for transferring such a data or there is no device that could receive the information.
It is also possible to preserve the information during the boot up sequence. If a crash is notified, the bootloader requests the BIOS to preserve the contents of the RAM during the boot. When new operating system boots up the preserved data is sent to a remote system that has a disk or other means for storing preserved information. The drawback of the solution is that the method requires support from the BIOS. However, all systems do not have a BIOS that supports this type of behavior. Thus, this method cannot be applied in every system.
The most sophisticated prior art method uses primary and secondary kernels. During the boot up the operating system's primary kernel kernel loads the secondary kernel in some predefined location of the memory. Upon crash, the primary kernel jumps to the secondary kernel and which sends the crash information to a remote system, which has a disk or other storage media. However, if the primary kernel crashes during the boot up sequence, it is possible that the secondary kernel has not been loaded yet. Thus, the method is not applicable in cases where primary kernel crashes before loading the secondary kernel.
Thus, there is a need for mechanism for preserving crash information so that a BIOS support is not needed and it must work reliably in all cases of OS problems in a diskless system. Furthermore, the solution should not relay too much on the crashed operating system to preserve the RAM contents.